Docker Scout es la apuesta de Docker Inc. por meterse en la conversación del container security, un mercado dominado por herramientas de terceros. Alcanzó disponibilidad general en 2023 y durante el último año ha madurado hasta convertirse en una pieza visible dentro de Docker Desktop, la CLI y Docker Hub. El planteamiento es claro: si ya pagas Docker Hub o distribuyes imágenes a través de él, el análisis de vulnerabilidades debería estar un paso detrás del docker push, no en otro producto de otro vendor.
La competencia no es trivial. Trivy, de Aqua Security, es el estándar de facto en CI open source. Grype, de Anchore, ocupa un nicho similar con foco en SBOM. Snyk Container juega en la liga enterprise, con un scope mucho más amplio que abarca código, dependencias, IaC y contenedores bajo un mismo panel. Scout no inventa el escaneo de CVE; lo que aporta es la integración nativa en el flujo de trabajo Docker y una feature que sí es distintiva: recomendaciones de imagen base.
Qué hace y cómo se usa
El modelo mental es el habitual de cualquier scanner moderno: se genera un SBOM de la imagen, se cruza con una base de CVE (Scout combina las advisories de Docker Hub con NVD y varias fuentes ecosistema-específicas como GitHub Security Advisories para paquetes npm o PyPI), y se reporta por severidad. A partir de ahí Scout añade dos capas: recomendaciones concretas de qué imagen base adoptar para eliminar CVEs, y evaluación de políticas organizacionales que puede fallar el build en CI.
El comando principal no tiene sorpresas:
# Análisis CVE de una imagen local
docker scout cves my-app:1.0
# Recomendaciones de imagen base (la feature diferenciadora)
docker scout recommendations my-app:1.0
# Diferencia entre dos tags: útil antes de promover a producción
docker scout compare my-app:1.1 --to my-app:1.0
# Evaluación de policies declaradas en la organización
docker scout policy my-app:1.0
En Docker Desktop el flujo es aún más invisible: el panel de Images muestra el conteo de CVEs por severidad junto al tag, y un click abre el detalle con la sugerencia de imagen base. Para el desarrollador sin background en seguridad, esa fricción cero es el punto fuerte real del producto.
Integración en CI y modelo de policies
La integración con GitHub Actions se apoya en docker/scout-action@v1, que acepta comandos encadenados (cves, recommendations, compare, policy, sbom) y filtros por severidad. En un pipeline típico conviene separar dos momentos: un chequeo de compare contra la imagen actual de producción, que detecta regresiones introducidas por el commit, y un chequeo de cves con only-severities: critical,high y exit-code: true como quality gate duro. El primero previene empeorar; el segundo impone un suelo absoluto.
Las policies son el mecanismo por el que Scout se convierte en algo más que un scanner. Son reglas declarativas evaluadas contra la imagen y sus metadatos: ausencia de CVEs críticas, ausencia de CVEs altas ya presentes en la base (es decir, culpa del mantenedor de la base, no tuya), requisito de firma, antigüedad máxima de la base, coincidencia con el lenguaje del proyecto. Bien usadas, desplazan la conversación de “cuántas CVEs tiene esta imagen” a “¿cumple esta imagen el contrato que nos hemos impuesto?”, que es una pregunta mucho más útil para bloquear un deploy.
El pricing es el elefante en la sala. El escaneo local con Docker Desktop y CLI es gratuito. El monitoring continuo, las policies a nivel de organización y el análisis sobre repositorios en Docker Hub requieren Docker Team (alrededor de 11 USD/usuario/mes a fecha de este artículo) o Docker Business (alrededor de 24 USD). Es razonable para un equipo que ya paga Hub; es caro si lo único que querías era reemplazar un trivy image en tu CI.
Scout frente a Trivy, Grype y Snyk
La comparativa honesta no es “cuál encuentra más CVEs” (en el día a día encuentran esencialmente las mismas, porque beben de fuentes solapadas), sino “cuál encaja en tu topología operativa”. Trivy gana cuando el equipo valora software open source (Apache 2.0), autohospedaje completo sin dependencia de un SaaS, y scope ampliado más allá del contenedor: Trivy escanea también sistemas de ficheros, repositorios git, configuraciones de Kubernetes y manifests de IaC. Grype gana cuando el caso de uso está centrado en SBOM de alta fidelidad y generación vía Syft, que es el pipeline estándar en organizaciones que ya están alineadas con SLSA.
Scout gana cuando el equipo ya vive dentro del ecosistema Docker: Desktop es la herramienta de desarrollo, Hub es el registro, y la fricción de instalar y mantener una herramienta adicional de terceros no compensa. Las recomendaciones de imagen base son el mejor argumento técnico: no he visto otro scanner comercial que sugiera de forma tan directa “cambia de node:18-slim a node:20-alpine y elimina 3 críticas y 13 altas, conservando las mismas dependencias”. Esa información existe en todos los scanners como datos dispersos; Scout la presenta como decisión ejecutable.
Snyk Container es otro animal. Su propuesta es cubrir todo el ciclo SDLC bajo un mismo paraguas. Si una organización ya ha estandarizado en Snyk por el lado del código y las dependencias, añadir Snyk Container es el camino natural y Scout no aporta suficiente. Al revés, si el único vector de seguridad que se quiere cubrir son las imágenes de contenedor, Scout es más barato y más simple.
Limitaciones honestas
Scout es closed source. Para equipos con requisitos de auditabilidad del propio scanner (sector público, banca), esto es bloqueante y lleva inevitablemente a Trivy o a productos con versión autohospedable como Aqua Enterprise o Anchore. La base de datos de CVE de Scout no es peor que la de Trivy, pero es opaca: no puedes inspeccionar las heurísticas de matching ni los false positives conocidos con la misma facilidad.
El segundo problema es el Docker-centrismo. Si tu registro no es Docker Hub sino GHCR, ECR o Harbor, Scout funciona pero pierde la mitad de su valor: el monitoring continuo y las policies a nivel de registro solo aplican en Hub. Para equipos que huyeron de Hub por los límites de pull en 2020, esto es un vendor lock-in encubierto.
El tercero es el de siempre: los false positives. Scout, como cualquier scanner, reporta CVEs que están en el SBOM pero que son inexplotables en el contexto concreto (código no alcanzable, versión parcheada por backport de la distro, mitigación en capa superior). El ecosistema se mueve hacia soluciones basadas en VEX y reachability analysis, pero en agosto de 2024 sigue siendo trabajo manual clasificar la señal del ruido.
Conclusión
Docker Scout es un producto competente que tiene sentido cuando el ecosistema operativo ya es Docker de extremo a extremo. Su integración con Desktop y Hub es frictionless, sus recomendaciones de imagen base son genuinamente útiles para desarrolladores sin expertise en seguridad, y sus policies permiten convertir el escaneo en quality gate real. No es la mejor herramienta por capacidades de detección (empata con Trivy y Grype) ni la más barata (Trivy es gratuita), pero sí es la que ofrece menor fricción si ya pagas Hub. Para equipos medianos sin security champions dedicados, esa fricción baja es lo que determina si la herramienta se usa o se deja de lado después de tres semanas. Para equipos con cultura open source establecida o requisitos de auditabilidad, Trivy sigue siendo la elección correcta. La decisión no es técnica en el sentido estricto; es operativa y cultural.